[Remoting] - Holding lock in HTTPClientInvoker.useHttpURLConnection()
by JohnBat
Hello all
I am using Jboss remoting 2.2.2.SP1. End I get lock during use
JBoss WS with Jboss Remoting:
------------------
"http-0.0.0.0-8080-20" id=113 idx=0x1c4 tid=23314 prio=5 alive, in native, daemon
at jrockit/net/SocketNativeIO.readBytesPinned(Ljava/io/FileDescriptor;[BIII)I(Native Method)
at jrockit/net/SocketNativeIO.socketRead(SocketNativeIO.java:46)
at java/net/SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I(SocketInputStream.java)[inlined]
at java/net/SocketInputStream.read(SocketInputStream.java:129)[optimized]
at java/io/BufferedInputStream.fill(BufferedInputStream.java:218)
at java/io/BufferedInputStream.read1(BufferedInputStream.java:258)
at java/io/BufferedInputStream.read(BufferedInputStream.java:317)
^-- Holding lock: java/io/BufferedInputStream@0x28535a48[biased lock]
at sun/net/www/http/HttpClient.parseHTTPHeader(HttpClient.java:687)[optimized]
at sun/net/www/http/HttpClient.parseHTTP(HttpClient.java:632)
at sun/net/www/protocol/http/HttpURLConnection.getInputStream(HttpURLConnection.java:1000)
^-- Holding lock: sun/net/www/protocol/http/HttpURLConnection@0x28511d50[biased lock]
at java/net/HttpURLConnection.getResponseCode(HttpURLConnection.java:373)
at org/jboss/remoting/transport/http/HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:280)
at org/jboss/remoting/transport/http/HTTPClientInvoker.transport(HTTPClientInvoker.java:135)
at org/jboss/remoting/MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
at org/jboss/remoting/Client.invoke(Client.java:1634)
at org/jboss/remoting/Client.invoke(Client.java:548)
at org/jboss/ws/core/client/HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:226)
at org/jboss/ws/core/client/SOAPProtocolConnectionHTTP.invoke(SOAPProtocolConnectionHTTP.java:77)
at org/jboss/ws/core/CommonClient.invoke(CommonClient.java:340)
at org/jboss/ws/core/jaxws/client/ClientImpl.invoke(ClientImpl.java:300)
at org/jboss/ws/core/jaxws/client/ClientProxy.invoke(ClientProxy.java:166)
at org/jboss/ws/core/jaxws/client/ClientProxy.invoke(ClientProxy.java:152)
at $Proxy913.queryOfferings(Ljava/lang/String;Lru/cti/oss/iptv/billing/api/resource/Service;)Ljava/util/List;(Unknown Source)
at ru/cti/oss/iptv/integration/billing/adapter/pull/external/PricingServiceAdapterPullBean.queryOfferings(PricingServiceAdapterPullBean.java:53)
at sun/reflect/GeneratedMethodAccessor2947.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(Unknown Source)
at sun/reflect/DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)[optimized]
at java/lang/reflect/Method.invoke(Method.java:597)[inlined]
at org/jboss/aop/joinpoint/MethodInvocation.invokeNext(MethodInvocation.java:112)[optimized]
at org/jboss/ejb3/interceptor/InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org/jboss/ejb3/interceptor/EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org/jboss/aop/joinpoint/MethodInvocation.invokeNext(MethodInvocation.java:101)[optimized]
at org/jboss/ejb3/entity/TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)[optimized]
at org/jboss/aop/joinpoint/MethodInvocation.invokeNext(MethodInvocation.java:101)[optimized]
at org/jboss/ejb3/AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)[optimized]
at org/jboss/aop/joinpoint/MethodInvocation.invokeNext(MethodInvocation.java:101)[optimized]
at org/jboss/aspects/tx/TxPolicy.invokeInNoTx(TxPolicy.java:66)
at org/jboss/aspects/tx/TxInterceptor$NotSupported.invoke(TxInterceptor.java:102)
at org/jboss/aop/joinpoint/MethodInvocation.invokeNext(MethodInvocation.java:101)[optimized]
at org/jboss/aspects/tx/TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org/jboss/aop/joinpoint/MethodInvocation.invokeNext(MethodInvocation.java:101)[optimized]
at org/jboss/ejb3/stateless/StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)[optimized]
at org/jboss/aop/joinpoint/MethodInvocation.invokeNext(MethodInvocation.java:101)[optimized]
at org/jboss/aspects/security/AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)[optimized]
at org/jboss/ejb3/security/Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)[optimized]
at org/jboss/aop/joinpoint/MethodInvocation.invokeNext(MethodInvocation.java:101)[optimized]
at org/jboss/ejb3/ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)[optimized]
at org/jboss/aop/joinpoint/MethodInvocation.invokeNext(MethodInvocation.java:101)[inlined]
at org/jboss/ejb3/asynchronous/AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)[optimized]
at org/jboss/aop/joinpoint/MethodInvocation.invokeNext(MethodInvocation.java:101)[optimized]
at org/jboss/ejb3/stateless/StatelessContainer.localInvoke(StatelessContainer.java:240)[inlined]
at org/jboss/ejb3/stateless/StatelessContainer.localInvoke(StatelessContainer.java:210)[inlined]
at org/jboss/ejb3/stateless/StatelessLocalProxy.invoke(StatelessLocalProxy.java:84)[optimized]
at $Proxy137.queryOfferings(Ljava/lang/String;Lru/cti/oss/iptv/billing/api/resource/Service;)Ljava/util/Collection;(Unknown Source)
----------------------
I seen in JIRA and don't find this bug.
Q1: Why this appears?
Q2: In which version this bug resolved?
My tomcat threads don't release from this lock.
previously, thanks. ;)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217351#4217351
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217351
17 years, 3 months
[JBoss Tools (users)] - Re: Feedback on the Smooks editor
by max.andersen＠jboss.com
Warning - I am a smooks noob, just have that in mind when reading my answers :)
"mzeijen" wrote : anonymous wrote : No matter if we use a custom classloader we would need to have a *very* stable API to do this since we would compile against liet say Smooks 1.0 would our code be able to use Smooks 1.1, 1.2 etc. without updating the binaries ? - does Smooks provide that ?
|
| I believe you need to implement a strategy pattern that can handle every supported Smooks version. For example something like this:
|
| - SmooksReaderStrategy interface
| - Smooks1_0ReaderStrategy class
| - Smooks1_1ReaderStrategy class
|
Of course, the problem is just that the two models of Smooks 1_0 and Smooks 1_1 is vastly different so I'm not sure any strategy can be defined that would work. But of course if it is doable then sure.
anonymous wrote :
| Every one of those implementations knows how to use one specific version of Smooks. So they also have dependencies on that specific version.
|
Of course they have an dependency to a specific version (or rather version range Smooks 1.1.x and 1.0.x) but that does not mean they have a compile nor runtime dependency on the Smooks binaries.
anonymous wrote :
| That is why you can't build against only one version of Smooks, you need to build against all of them.
|
I develop an IDE that is compiled against Java 5 and it supports Java 1.1 to Java 6 without any build dependency to each specific version.
Same goes for our AS, jbpm, hibernate (to some extent), esb, jbossws annd other tooling. If we had to depend on *every* runtime version of these we would have a gigantic monster ;)
anonymous wrote :
| Because you can't do that within one bundle, you need to split it up in multiple bundles. The parts of the Smooks editor could then look something like this:
|
| - SmookEditor
| - SmooksReader API
| - Smooks1_0Reader implementation
| - Smooks1_1Reader implementation
|
| If I understand OSGI correctly then you wouldn't even need to worry to much about classloading, because every bundle can have it's own independent bundle dependencies.
|
Sure, but we would now be bundling how many versions of Smooks ?
What about smooks 1.0.1, 1.0.2, 1.1.0, 1.1.1 etc ?
anonymous wrote :
| The SmooksEditor would have dependencies on the SmooksReader API and all it's implementations. Every implementation would a dependency on one specific version of Smooks.
which means if smooks 1.2 comes out we would need to redo/adjust the tooling before the tooling can read understand it even if the syntax is 90% the same ...
anonymous wrote :
| You could even make every reader a separate Eclipse plugin. That way you could implement new Readers for new versions of Smooks and use them with older versions of the editor. You only need to install the plugin.
|
If we somehow can create a model from the internal smooks model that is independent of it then I agree this could work - but users who have to have perfect syntactically correct files all the time.
anonymous wrote :
| anonymous wrote : And what about the model that we load - is that stable ? I'm asking since I don't know :)
|
| The model that the Smooks editor gets from the Readers wouldn't change in between Smooks editors because they would belong to SmooksReader API. The Reader implementations would take care of the proper translation between the model that Smooks uses and the model that the Editor uses.
|
The Reader you mention in that paragraph is from Smooks or from the Smooks plugin ?
anonymous wrote :
| anonymous wrote : About partial documents then users don't have syntax correct files - they type and it will be imperfect. That would mean as soon as the user type the graphical editor would not be able to show anything - that might be ok as you write it.
|
| Yeah, you would have that same problem with the current Smooks editor. The editor would need to tell the user that the source model can't be read because of a syntax problem.
|
the current editor at least in theory can survive broken parts and still read the rest.
anonymous wrote :
| anonymous wrote : Another issue is that Smooks might not be able to load any of the related classes referred to in the editor because the classes are not compiled yet - does it support that ?
|
| No, Smooks doesn't currently support that. In this special case we would need a special reader. Maybe we can reuse the code that is now used by the editor to read the java model?
|
If we can pass in a strategy then sure.
anonymous wrote :
| I think that the Smooks team would be happy to provide support for implementing any special readers like that special Java reader or a XSD reader. I know I would at least ;).
Great :)
p.s. I'll meet up with Dart who have been doing the smooks editor at EclipseCon in 2 weeks time where we will discuss this so keep the ideas flowing ;)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217349#4217349
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217349
17 years, 3 months
[EJB/JBoss] - JBOSS - 5 , EJB 2.0 Stateful Session Bean
by gbsendhil
Hi i am currently migrating my application from jboss 3.2.6 to jboss 5.0.0.
The problem i am facing here is the bean is loosing its data. The same code works well in jboss 3.2.6
ejb-jar.xml
<!-- Session Beans -->
<display-name>Meeting Bean</display-name>
<ejb-name>MeetingBean</ejb-name>
com.pbvm.crr.api.ejb.MeetingHome
com.pbvm.crr.api.ejb.Meeting
<ejb-class>com.pbvm.crr.impl.ejb.MeetingBean</ejb-class>
<session-type>Stateful</session-type>
<transaction-type>Container</transaction-type>
The Code
//Get the Meeting Session Bean Home & Remote Objects.
try {
object = utils.getHomeInterfaceApp(ejb/CreateMeetingStateful);
meetingHome = (MeetingSessionHome) PortableRemoteObject.narrow(object,MeetingSessionHome.class);
if (null == meetingHome) {
throw new InvalidParamException("MeetingSession Home Object" + " is NULL");
}
Logger.debug("Got the Meeting Home Interface ");
meetingRemote = meetingHome.create();
} catch (Exception e) {
Logger.debug("Exception while MeetingSessionBean Home Interface ");
throw new CRRException("CRRException ", e);
}
//Getting the Preview Value Object from Meeting Stateful Session Bean.
StateFulBeanManager sManager = new StateFulBeanManager();
previewVO = sManager.getPreviewVO(objectHandle);
Here the object is null.
Should i do anything explicitly in JBOSS- 5 to get the stateful bean .
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217331#4217331
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217331
17 years, 3 months