JSLEE Discussions
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: stevena
Forum Index » Profile for stevena » Messages posted by stevena
Author Message

You need to define management operations in the Profile Management Interface or business operations in the Profile Local Interface. You implement these in the Profile Abstract Class, and the implementation code can get the usage parameter set and update the counters, etc.

It's possible you could expose the usage parameters getter method in the Profile Local Interface, or some other delegatory method, if you wanted to expose the profile's usage states to an SBB.
There are no tools included with rhino that will export a single profile. If you're up for it you could write a simple management client though that does do this by using ProfileProvisioningMBean.exportProfiles - this is the API that the exporter tool uses to export profiles.

(Yes that's a link to the Rhino 2.6.0 API javadoc. I couldn't find a link to the Rhino 2.3.0 API but AFAICT that API hasn't changed since 2.3.0 so should still work there.)
rhino-console is fairly simplistic in the types of strings that it will parse and unfortunately in this case it can't do what you are needing.

You could still do it using rhino-console using the xml profile export/import format (using rhino-console's importprofiles command), just not using setprofileattributes.
No, stats are only reported as they occur, they are not recorded or archived anywhere by Rhino.
You can manually remove the hanging SBB using, for example, the findsbbs and removesbb commands in rhino-console.

The getsbbinfo command can be used (before you remove the SBB) to find out why it's hanging. Most likely it's still attached to an activity that has not ended yet. The findactivites, getactivityinfo, and removeactivity commands can be used to manually inspect and clean up those too.
Installing JDBC drivers as library jars is really not the right approach you should be taking, but anyway, you find a line like below in read-config-variables (production Rhino) or config/jvm_args (Rhino SDK):


If you uncomment that line and restart the node, the Java security system will dump lots of debugging information about security accesses. When your access control permission failure occurs you can find out which protection domain failed the permissions check.

Given that it appears to be a thread started by the JDBC driver that's failing the permission check, resolving this might be difficult. Using a AccessControl.doPrivileged() block around the code that starts the thread(s) might work, if you know where that occurs.
Try putting double quotes around the component ID. The space in the middle of the component name will be causing the parser to read too many tokens.
CMP is your answer. If there's a number of different things you need to store you can use as many CMP fields as you need.
This looks rather suspicious in the simulator log:
2017-05-29 16:18:08,715 | DEBUG | main | cgin-tcap.sua.asp-manager | adding acceptor for
2017-05-29 16:18:08,715 | DEBUG | main | cgin-tcap.sctp.netty.connection-manager | Adding acceptor:
2017-05-29 16:18:08,751 | WARN | main | cgin-tcap.sua.asp-manager | failed to initialize listen socket: Unable to bind to socket: Failed to bind to: /

Something else to look at is the debug logs from the SIS. Possibly the OpenRefuse was generated simply because it couldn't connect to the endpoint you expected to be listening. There could be another reason, but you'd need to look at the debug logs to find out.
Thanks for the log. I'm a bit confused by this though:

Symbolic links exists /work -> /opt/RhinoSDK/work
/work is owned by rhino.rhino

You said /work is a mount point, so it can't be a symbolic link. Do you mean it the other way around, ie. /opt/RhinoSDK/work is a link to /work?

You also said:

/opt/RhinoSDK/config/config_variables contains

but in the logs you provided work/config/config_variables contains RHINO_WORK_DIR=/opt/rhino/work. Ignoring that it's "rhino" instead of "RhinoSDK", what I'm getting at is that it's a path under /opt, not /work.

Can you attach the complete rhino log please?
Any fire event method in an SBB will do what you want.

Fire event methods are inherently asynchronous - the event is only actually fired if and when the SBB event handler transaction commits - and the SBB will only receive any response, if there is one, sometime later if the SBB has an event handler for the response event and the SBB is attached to the activity context of the activity that the response event is fired on, or has flagged the response event as an initial event. If the SBB doesn't fulfil these conditions it won't see the response, so in your case you just have to make sure that these conditions are not fulfilled.

Ok yes, your SIS version is too old. The ECS1:allow-camel-style-apply-charging extension option was added in SIS 2.5.2.

The extension options supported by a given SIS version are listed in the formal documentation, for example on this page and this page (though the ECS1 extension option is oddly missing from that second page - it should be listed there too). Unfortunately only the latest versions of the docs are posted on the devportal for each major release, so the current SIS 2.5 docs are for 2.5.4.

It would actually be a good idea to have something like a console command that listed the available extension options. I'll make a note of that for a potential future enhancement.

Unfortunately I can't see anything unusual in the log and my own tests under what I presume to be similar conditions works as expected.

What version of the SIS are you using?
Can you attach a debug log showing the entire call processing in the SIS? ie. set the root tracer in the sis_in resource adaptor entity to debug level and make the call.
Forum Index » Profile for stevena » Messages posted by stevena
Go to:   
Powered by JForum 2.1.8 © JForum Team